1. Technical Field
This invention relates generally to systems for allowing a user to iteratively and automatically negotiate developments of products and programs.
2. Background
Business entities have tried for years to adapt computers and networks for use in sophisticated intercompany negotiations for commercial purchase and sales transactions, but with results that usually fall far short of expectations. Early mainframe computer attempts, for example, usually involved one corporation's allowing its existing suppliers and quantity buyers to connect to its internal private, proprietary network, using specially written locally developed application programs and private, proprietary network connections. These private systems were usually extremely costly to develop and maintain (often costing in the multi-millions of dollars) and very often did not meet all the needs and changing requirements of the participating businesses. Since many corporations had different internal networks and computer systems, considerable effort went into working around incompatibilities. Additionally, these systems had to be based on already existing, close relationships between buyers and sellers and usually were also based on previously negotiated agreements. Thus, the systems did not help in searching for information about new buyers and sellers, nor with the evaluation or negotiation processes, nor with the documenting of those processes from the beginning. They were not interactive, but typically batch processing systems, and usually accepted alphanumeric text only, not the inclusion of graphics or sound files. They usually addressed ongoing relationships previously worked out manually, for which extremely expensive custom systems were developed at buyers' or vendors sites.
Most business (and many other) negotiation processes are usually multivariate. That is, a business negotiation deals with many variable items, such as price, quantity, quality, shippers, insurance, warranty, schedules, returns and so on. The above solutions typically did not automate multivariate negotiations in any way, since they had to be built on agreements whose terms had all been previously negotiated.
With the advent of the Internet and the World Wide Web (Web), the exchange of information amongst companies was greatly enhanced, with the use of Web technologies. However, even with chat rooms, bulletin boards, and forum websites most of this data and information exchange is simply that—not a multivariate negotiations process nor an online, electronic commerce process.
While some of the Web devices, such as chat rooms and bulletin boards are interactive, each essentially allows two or more people to have conversations over the Internet, in the same way they might speak over the telephone or several might speak over an old-fashioned party line telephone. While the chat room or bulletin board may store these conversations, no other action takes place as a result of the process. Consequently, privacy and security questions aside, these are not effective devices to use to negotiate a number of variable terms, reach agreement on each and document the results. Just as telephone conversations about negotiations can be recorded on tape, but do not produce a contract document on paper, online chat or bulletin board discussions about negotiations cannot easily be used to make a contract on the network, even if they are archived.
Extranet Web technology has been developed to enable a corporation to “talk to” (but not negotiate multiple variables in iterative bargaining with) its suppliers and buyers over the Internet as though the other companies were part of the corporation's internal “intranet.” This information exchange is done by using client/server technology, Web browsers, and hypertext technology used in the Internet, on an internal basis, as the first step towards creating intranets and then, through them, extranets.
In typical intranet client/server technology, one computer acts as a Web server computer to perform complex tasks, while other, smaller computers or terminals are “clients” that communicate with the Web server. In typical client/server intranets the client requests data and performance of tasks from the Web server computer. A Web server program runs on the Web server computer to provide Web server functions. The communications between these intranet clients and Web servers is in Hypertext, or HyperText Markup Language (HTML)—the “language” of the Internet's World Wide Web.
Usually, for intranets, at the Web server site, one or more people would create documents in hypertext format and make them available at the Web server. In many companies, employees have personal computers or terminals at their desks connected to the internal network. In an “intranet” these employees would use a Web browser on their terminals to see what hypertext documents are available at the internal corporate Web server site.
While this has been an advance for internal communications over a private network, it does not usually provide any interactive, iterative, multivariate negotiations capabilities and it requires personnel familiar with HyperText Markup Language (HTML) to create hypertext links in documents to create and maintain the “internal” Web pages. If a more interactive approach is desired, an Information Technology (IT) specialist in some form of scripting, such as CGI, or PERL is needed who can create forms documents and procedures to allow users to ask for information from the Web server. Again, this is custom programming at the user's site, and still does not provide multivariate negotiations or commerce capabilities.
Corporations that share information internally can also use workgroup software such as IBM's LOTUS NOTES™ software on the internal network. However, this, too, requires special programming and scripting for the unique needs of the organization, and normally does not address multivariate negotiations, even on an internal basis.
Since extranets simply extend a company's intranet to include selected other companies, the extranet concept usually does not provide any negotiations capabilities, either, much less electronic commerce capabilities.
To date, most attempts at adapting Internet technology to negotiations and commerce, even in small measure, have been focused on solving the problem from inside a corporation's systems going out and with the emphasis on the seller, not the buyer. Consequently, Intranet/Extranet options usually do not provide electronic commerce, only more sophisticated information distribution and sharing.
For corporations that sell at retail, one technique for selling goods over the Internet 04 is shown in FIG. 2b (Prior Art). This scheme uses the concept of a hosting “mall” 24 Website that enables buyers to browse through stores 28 (individual participating selling corporate Websites or aggregated catalog systems) and use a “shopping cart” 26 feature for selecting items to purchase. Participating sellers in a mall 24 create their own Websites which list items for sale and prices. The mall usually provides the shopping cart technique for the buyer to use to select items to buy. Such Internet 04 sales techniques also use security systems for transmitting payments by credit card 30aand 30b or CYBERCASH™ payment methods (not shown). Most of these mall Website are significantly limited in the interaction, if any, they allow between buyers and sellers. A few allow limited price negotiations between buyers and sellers, but none allow iterative, multivariate negotiation and bargaining for both price and terms, such as availability, shipping, carrier, payment methods, risk of loss, etc.
Similarly, for non-retail business buyers and sellers, the mall concept above has limited value, since it usually does not connote much about the integrity or capability of the participating businesses, nor provide all of the various payment options a business might want to use. Most of the present Internet and World Wide Web systems for commerce are directed to consumer purchases of retail items in small quantities, not to business to business transactions or consumer transactions negotiating for goods and services in large quantities on national or international terms.
The companies that do provide more of a business to business focus over the Internet usually do so by offering special enterprise application server software 19s, as shown in FIG. 2a (Prior Art) for installation inside an enterprise's private corporate network. These programs fit into a category of software called front-office applications or application servers—so called because they sit close to the user end inside an enterprise and are customized to interface with the back-office applications 21 inside the enterprise, which include commercial products from software suppliers as well as custom developed applications that handle internal business functions such as inventory tracking, financials, human resources and supplies, and similar Enterprise Resource Planning (ERP) systems.
As seen in FIG. 2a (Prior Art), three separate corporations 16a, 16b and 16c are shown using the services of an enterprise commerce site provider 18. Each corporate site 16 has a firewall 16af, 16bf, and 16cf. Firewalls are a combination of hardware and software designed to prevent unwanted intrusion into a private corporate network by unauthorized personnel. A firewall usually puts a specially programmed computer system between its internal network and the Internet. It also prevents the company's internal computer users from gaining direct access to the Internet, since the access to the Internet provided by the firewall computer is usually indirect and performed by software programs known as proxy servers.
Note that, as shown in FIG. 2a (Prior Art), in a typical implementation of an enterprise commerce site provider 18, the enterprise commerce site provider 18 breaks through the firewalls 16af-16cf of each of its customers. Normally this is done in such a way as to provide secure access. Occasionally, if the commerce site provider 18 allows its customers to be linked for certain transactions over the Internet 04, over a common external link 10 to the Internet, internal security may be comprised, if the customer's firewall is configured incorrectly and the Internet transmission results in a breach.
Still in FIG. 2a (Prior Art), note that the typical enterprise commerce site provider 18 must have each customer 16 install the provider's application server software 19s, on an application server computer 19h inside the corporation's private network 14. Thus, in order to have access to the commerce site, corporation 16a would have an individual working at a desktop computer 08, for example, connect to the corporation's internal Web server computer(s) 20h over internal private network 14. The corporate employee thus accesses the enterprise commerce site provider 18 through his or her corporation's Web server computer 20h, running the enterprise commerce site provider 18's application server software 19s. From the Web server 20h, application server software 19s, possibly running on its own application server computer 19h communicates through the firewall 16af with enterprise commerce site provider 18, and ultimately, through that site to other corporate subscribers to the enterprise commerce site provider, 18 usually over a private leased network 11. The corporation's internal network 14 links the desktop computers 08 with not only the internal application server 19, but also to the internal corporate back-office internal computers 21.
Many, if not most, of the implementations of the enterprise commerce systems shown in FIG. 2B (Prior Art) may also require the corporation to install a special database application server 13h, to run special database application software 13s along with the application server software 19s. Thus, if the corporation already has a Web server computer 20, and the corresponding software 20s, it still has to purchase at least the application server software 19s, possibly an additional computer to act as the application server computer 19h, and possibly yet another combination of database server computer 13h and database server software 13s, in order to use the enterprise commerce provider 18's system.
Because application server products 19h and 19s, and possibly additional database server hardware and software as seen in FIG. 2a(Prior Art), have to be installed inside each participating corporation, customized to that corporation's internal back office systems 21, and backed by appropriate internal training support, it can cost in the several hundred thousands or millions of US dollars to purchase and install the systems and train internal people on their use. While a few of these applications connect buyers and sellers over the Internet, usually both the sellers and the buyers must also install and customize the application server software 19s inside their internal networks 14—another reason why these systems are so expensive, difficult to implement and costly to maintain. The traditional approach has been to design systems that will interface with the corporation's own internal computers and systems. Since these vary from one company to another, this is another reason why the application server software 19s can be costly, as extensive modifications to it may be necessary to interface with each customer corporation's own systems.
Payment options in an enterprise application server approach may be a little broader than those in a mall, in that they include not only credit cards (for those following the US banking systems) or CYBERCASH™ payments, but also procurement cards or specially agreed upon and custom programmed electronic authorization methods that allow a buyer to order items from a seller. However, for both enterprise application server and the mall Website approaches, payment processing, especially by credit card, is complicated.
In order to process a credit card transaction, a number of communications need to occur between selling Website and the bank/credit card processor. If the bank/credit card processor accepts “international” payments, any currency translations are done in separate steps, not online or in real time. That is, they are usually done on a special processing basis, rather than part of an online transaction, if they can be done at all in some countries. A general overview of the steps required for credit card handling is shown below:
Enterprise server/mall WebsiteBank/credit card processor1. transport the credit card2. verify the card is legitimate and theinformation securely toamount exists; send authorization toprocessor or bank over a privateonline merchant over the privatenetwork;network;3. post the item details back to4. transport item details to card issuerthe bank/credit card processorfor debit to the holder's account overover the private network;private network5. make necessary currency translation(usually offline)6. credit the merchant account7. deduct significant fees, usually apercentage or more per transaction fromthe merchant account;8. archive details.
Credit cards are issued to buyers relatively easily, but merchant identifiers (merchant ID's), which allow the merchant to accept and process the cards are not as easy to obtain, especially for online transactions, and online merchants are usually charged premium processing fees to authorize online processing and the handling of international transactions.
Procurement cards or other custom programmed electronic authorization methods that allow a buyer to order items from a seller are usually more expensive in that they usually require special negotiations' and some custom programming. Any time custom programming is required, along with local installation and training at the corporation's site, costs go up significantly.
Because of this expense, enterprise application server systems, such as those provided by CONNECTINC.COM and TRADE'EX.COM are designed to work with existing relationships between buyers and sellers, in which the detailed terms have already been negotiated for ongoing purchases and to prevent “wild card purchasing” inside the organization. These are usually referred to as maintenance, repair and operations (MRO) or administrative purchasing. Generally, administrative purchasing only represents about 20% of a company's purchasing efforts. Within this administrative level of purchasing, procurement cards and specially constructed payment methods are used more for the low value transactions. More important MRO transactions are usually paid for by company checks or wire transfers. Most of a corporation's purchasing efforts, nearly 80% in many cases, are directed to production purchasing, which is usually not addressed by the above types of enterprise systems.
In marketing literature, for example, TRADE'EX states that its TRADE'EX procurement system is specifically designed to be an MRO system which “frees buyers to concentrate on more important tasks such as vendor selection and contract negotiation.” That is, it does not handle production purchasing and negotiations.
Production purchasing is normally defined as the purchasing of components, subassemblies or parts that a company assembles and repackages into its own products. If a company manufactures automobiles, for example, production purchasing for it includes the purchasing done for all the components of its automobiles—tires, batteries, electrical systems, seats, engine parts, raw materials for frames, etc. For an auto manufacturer, MRO or administrative purchasing would handle such lower priority items as office supplies, office furniture, etc., or established long standing items such as stock tires for automobiles for which all the terms had previously been negotiated without the benefit of automation.
Production purchasing includes the selection of new vendors, the evaluation of them and their products, conducting contract negotiations and so on. It is also of strategic importance to a business because it has a very direct impact on manufacturing and product costs, and sales prices. Thus, while the enterprise application server products do tend to reduce the internal transaction costs and time associated with MRO or administrative purchasing, they are usually affecting the smallest part of the purchasing effort, leaving the bulk of the endeavor, and often the most strategically important part to existing manual methods.
Credit cards are essentially ways to pay cash in advance for goods and services, and thus, would not be suitable for production purchasing either, where delivery, payment, and inspection schedules are usually negotiated to occur over time. Thus, in a production purchasing agreement, a buyer may only to agree to pay the seller in installments, after the seller has shipped a monthly quantity and the buyer has had a chance to inspect and accept them. Once the buyer has accepted a shipment, the seller would usually like the fastest payment possible. Even if credit card payments could be made after the fact, they are usually not handled online for international transactions.
In addition, obtaining real time card authorization for international transactions online is a major undertaking, because online card processing and bank to bank connectivity does not exist on the Internet in many countries. Also, transactions denominated in most non-G7 currencies are not likely to be processed in real time online because the international banking system is not capable of doing real time, online, Internet currency transactions. Consumers who travel and use credit cards to make payments in other countries, and other currencies, may think these transactions are being handled online, but they are not. Most of the currency exchange processing is done by the connecting banks offline, and most of it that is done electronically is done on private bank and interbank networks.
Many of the major credit card issuers also do not allow a merchant to use its merchant identifier (ID) to process transactions on behalf of related entities. This is a significant problem for mall operators, in particular. To add a new store to the mall, the mall Website operator must ask the store to get its own merchant ID, offline. It can take weeks to get a merchant ID, but without one, the seller in the mall cannot accept any online transactions at all.
For international processing there are other payment methods available, but these are usually done manually or offline. For example, wire transfers allow bank-to-bank payments for international transactions in any tradable currency. However, these are done over private bank networks and usually between companies which have already established a purchasing relationship—i.e. for MRO or administrative purchasing. Wire transfers are used more often in international trade than company checks, because the processing time for a wire transfer is faster than check processing and the fees charged by the banks are often lower. The participating banks usually handle the currency conversion as part of the process. Again, however, this usually requires some fairly sophisticated interbanking networks in the applicable countries.
Letters of credit (L/C) are another payment vehicle used for international transactions, once they have been negotiated. It usually takes 6 weeks or longer to negotiate one. Negotiations take so long because the issuing bank (the buyer's bank) assumes the total credit risk by agreeing absolutely to pay the seller so long as the transaction documents match the terms of the letter of credit itself. Most disputes about the payment of letters of credit have to do with discrepancies in the L/C terms, including such simple things as typographical errors. As seen in FIG. 2c (Prior Art) heretofore, letters of credit were negotiated primarily by telephone calls and facsimile exchanges between a buyer P1 and a bank P2 which can easily result in both substantive and typographical errors. Banks which process the letters of credit, often use a private network known as the SWIFT system, which provides 128 bit encryption for data sent between points on the SWIFT network. The United States Department of Commerce continues to regulate encryption controls required by US laws, and limits this full level of encryption to US and Canadian banks. Other systems are allowed to use 56 bit encryption outside the US and Canada.
Another form of payment often used by business for production purchasing is known as documentary collection. It is midway between a letter of credit and a wire transfer. With this method, the issuing bank does not assume the absolute credit risk and obligation to pay. It only agrees to assist the transaction as a sort of “honest broker.”Consequently, the bank fees are lower. However, this method is normally used between parties that have already established a course of dealing, but want a structured payment vehicle processed through their respective banks.
Still another payment method often used in business transactions is the purchase order (PO) issued against a previously agreed upon master purchase agreement. Some of the MRO or administrative systems which go beyond credit card payments, enable a buyer and seller to use the terms of a previously negotiated master purchase agreement as a governing document for each purchase order issued. In this approach, a purchase order represents a buyer company's obligation to pay according to the master agreement, and the seller has to accept the risk that the buyer will actually pay the purchase order per the originally negotiated payment terms. As with letters of credit, this form of payment usually involves the transmission of facsimiles and telephone calls between the businesses—an error-prone process.
For purchase orders, as with letters of credit, and similar techniques, one of the difficulties for businesses is known as the “battle of the forms.” If a buyer issues a purchase order, or ships goods against a letter of credit with different or additional terms stated or implied, in many jurisdictions it is not clear which contract terms will govern the transaction. Frequently forms get lost, or the exact order and dates of transmission and receipt are not known, or the contents are rendered unreadable by carbon copies or facsimile machines. There is usually no simple, reliable way to track all the steps involved in the transaction. Thus, transactions may be repudiated by buyers or sellers because the paperwork is incomplete or erroneous.
While some attempts have been made to address repudiation arising from terms sent fraudulently by other than the authorized buyer or seller, these attempts typically focus on obtaining some form of electronic signature or certificate of authenticity to avoid some of the difficulties. However these do not dear up unreadable terms or track down all the terms negotiation steps.
As mentioned above, some existing MRO systems provide MRO application server software at both the seller's and buyer's sites, which is installed and customized at those sites, to the internal systems used by each—the cost of such installation and customization is usually high.
In addition to the cost of the internal software installation and customization, enterprise MRO electronic commerce products usually do little or nothing to help a seller find new buyers (or the buyer find better, more cost efficient suppliers) or simplify the initial purchase and multivariate contract negotiation process. Most buyers want to be able to evaluate new suppliers readily. The negotiation of a major purchasing agreement with a new vendor for a new product may take anywhere from 6-12 months or more, if done manually. Since the existing enterprise application server products tend to focus on integrating with existing internal administrative/MRO corporate systems, very little, if anything is done by them to simplify the launching or negotiation of new buyer/seller relationships.
In many corporations, the selection of a new supplier for production purchases usually involves the creation of a team from purchasing, engineering, and manufacturing to evaluate all potential sellers. The team usually flies to potential vendor sites to evaluate capabilities and production facilities, obtain samples, and then return home to evaluate the samples.
For new product developments, the ability to evaluate actual samples as part of the buyer's new product may be critical to the buyer corporation's overall development strategy and product timetable, and thus, the bottom line. A mass storage device manufacturer that is developing a faster, cheaper, higher capacity disk drive, may need to find high capability read/write heads. Read/write heads with the characteristics needed by the mass storage device manufacturer may not be available from anyone on the market yet. However, the manufacturer probably knows several firms that make high quality read/write heads for existing devices. If these firms have new heads under development, they would usually be willing to provide evaluation samples to such a manufacturer. The manufacturer needs the samples to verify that the new disks it is building will work reliably and at full speed with the heads being developed by the other firm. If these tests can be performed and the results are good, the manufacturer knows it is likely to be able to meet a new product shipment date of x, with a price of y. If samples cannot be obtained and evaluated, the manufacturer's product development cycle may slip by months or years, thus costing potential millions in lost revenues and market shares.
Once a short list of vendors with acceptable samples has been qualified, the team would be represented by the purchasing buyer who negotiates with the different representatives from the vendor short list. When the buyer has selected a seller to buy from, it may still take 6 to 12 months or more to negotiate prices, sales terms, quantities, inspection and replacement terms, availability dates, shipping costs, carrier, risk of loss and insurance, payment options, etc. Most of these terms are critical for production purchasing. The cost of reaching agreement on all terms can come to thousands or tens of thousands of dollars worth of labor, travel, and other expenses normally associated with the typical production purchase negotiation, in addition to the delays caused to the buyer's development and production cycles.
As another example, if an automobile manufacturer plans to build x thousand new cars and trucks each month on its production line, it needs to be sure that the firm(s) from which it purchases the new types of batteries needed for new models can deliver the required quantity each month, on time, with excellent quality and reasonable prices. The auto maker could lose millions in sales if its assembly line is stopped because of part shortages. Thus, while price is important in production purchase negotiations, it is only one small part of an overall set of purchase term variables that are strategically important to the auto maker and its cost of goods sold. If the seller uses unreliable shippers and carriers or does not know how to import or export its goods to the manufacturer's assembly plants, the best price on the market will be worth very little to a manufacturer which has to halt production because of missed schedules, shipments, or quantities.
Obtaining samples from vendors known to the production buyer is significant in itself, as seen above. However, in today's international trade, the overwhelming majority of potential buyers and sellers are not aware of each other's existence. Yet international trade is increasing by double digit numbers each year, so an obvious need exists for more capability. Many countries are taking advantage of the “leapfrog” effect by using the Internet and the latest in information technology (IT) to build instant infrastructures for competing in international commerce. Some countries and trade regions have set up inspection services for potential outside buyers, so that a buyer can obtain an independent assessment of a particular vendor's production facilities from such services. This saves some time and travel expense. However, it still does not provide a buying team with samples for evaluation. With current Internet commerce systems there is no effective way to order such samples. By the time terms and conditions for a sample order have been negotiated manually at such distances, the samples are not likely to be relevant any longer to the buyer company's development goals.
At the same time, most sellers of such products may need time to ramp up their production (especially for new or improved products) in order to meet quantity terms and dates, and they may need to incur additional costs if they have to change shippers to meet the buyer's needs. A seller does not want to have its goods rejected arbitrarily as defective or damaged if this is not the case. So inspection, return and refund policies need to be negotiated. All of these terms are usually variable and may frequently interrelate. If a seller's shipping costs go up—so might its prices. If a buyer is unable to meet its quantity goals because too many of the seller's goods are defective, the buyer's internal costs go up, and the buyer may have to buy from another source.
Production purchasing negotiations such as these are usually done by telephone, on-site visits, faxes and other non-automated means of conducting a negotiation today. This work is labor intensive, and if travel is involved, expenses climb. If the transaction is an international one between two countries with different currencies, customs, and trade practices, it can take even longer and cost more to conduct the negotiations.
In today's global markets, while international sourcing is becoming more and more important, it is expensive for a buyer team to travel to sites in another country to evaluate them, buy samples for engineering evaluation at home, and to conduct the negotiation through occasional visits between buyer and seller. While most use facsimile machines or computer fax modems to submit drafts of agreements back and forth, face to face negotiations may be needed more frequently for international negotiations, because business practices in the two countries may differ significantly and errors or misreadings caused by poor fax reproductions may further complicate the process.
In other words, application server approaches do not offer any real solutions to the production purchasing, non-retail, problems.
Returning now for a moment to FIG. 2b (Prior Art), as mentioned above, Websites such as retail malls 24 or standalone Websites are used by some corporations which sell at retail. While many tools exist to allow companies to design Websites, there are not as many that allow a company to design one for automatic integration into a Website in a mall or with online catalogs. Since most companies want to maintain control over the appearance of their corporate and brand names, those mall or catalog sites that do provide Web tools for their business subscribers, usually do not provide complete common interfaces or templates for the companies to use, nor do they integrate the sites with multiple features and services. Instead, they usually only provide access to a shopping cart 26 feature and a secure credit card 30 payment feature with a catalog product and price list that is searchable. Some may also provide manual help to the seller in listing its Website in relevant search engines used on the Internet. Normally, however, it is the seller's responsibility to do so. In either case, the registration with search engines is usually done manually. Some may also require the seller to arrange for payment processing separately, offline. As mentioned before, obtaining a merchant ID can take weeks, thus limiting what the seller can do online until then.
Presently, on the Internet, search engines such as Compaq Corporation's ALTAVISTA™, Yahoo corporation's YAHOO™ and so on, have different schedules for accepting and adding new sites to their search lists. It can take anywhere from 4-8 weeks or more for a site to be registered with each search engine. Many Internet search engines also add entries to their lists by “spidering” around the Internet to gather all Website addresses. Depending on the search engine, spidering may take much longer or not be as complete as a user requested registration. For example, ALTAVISTA's Website states:                 The Altavista search engine starts by spidering your entire site with its spider Scooter. Scooter may take up to three months to spider and index your entire site. It normally spiders about 2 pages per site in any week. . . . Best bet is to submit your pages manually at the rate of no more than 30 per week.        
As can be seen, the costs to a seller to establish a Website can be significant both in time and money. IDC Corporation reported in 1997 that the average cost of creating a fully enabled domestic US business to business electronic commerce standalone, single, retail Website for a large Fortune 1000 business was approximately
600,000.00 (Six Hundred Thousand USD.)
BUSINESS MARKETING MAGAZINE™, published by ADVERTISING AGE™, reported in 1998 that median prices for creating a single Website averaged as follows:
Company/Website SizeAverage CostSmall $44,500Medium $99,750Large$302,975
To add electronic commerce to the site, costs averaged as follows:
Company/Website SizeAverage CostSmall$25,000 (online ordering by fax but no transaction orpayment processing)Medium$33,000 (online ordering with credit card processing)Large$78,000 (database searches, online ordering, credit cardprocessing)
Creating a single Website can take anywhere from 1-8 weeks to 6-8 months or more. Creating one that is able to handle simple electronic commerce transactions may take even longer as merchant accounts for credit cards need to be obtained, integrating CYBERCASH™ or similar realtime payment methods must be provided for, search engine registrations need to be requested and so on.
As noted above, generally accepted electronic methodologies for handling international commerce online other than on a simple credit card or CYBERCASH™ payment basis for retail sales do not exist. Many countries do not have bank procedures in place to accept international credit card transactions in real time. In such countries, trying to adjust the current banking systems may well be impossible and completely new systems would be needed.
Thus, most existing electronic commerce sites are designed to work with existing proprietary banking networks such as the United States VISA™ and MC MASTERCARD™ real-time card authorization and processing interbanking systems. As noted above, these are known as SWIFT-compatible private networks which use 128 key encryption for security. This often limits a buyer or seller's market potential unnecessarily. Since many countries do not have banking systems comparable to the SWIFT interbanking system, payments in such countries may only be made by manually negotiated letters of credit and so on. It can take from 46 weeks simply to negotiate the terms of a letter of credit, when using the same manual techniques of phone calls and fax machines. In a global economy, when manufacturers in one country may want to source parts and components from the Pacific rim, sell them in the United States, Europe or South America, or Pacific Rim, a system that does not address the complexities of international purchasing is very limiting.
Similarly, the companies that provide Web hosting for a mall 24 on the Internet as shown in FIG. 2b (Prior Art) usually address only retail sales of consumer articles, with little or no control over the individual businesses that subscribe as sellers or the consumers who browse as buyers. In many business transactions, buyers want to know that the sellers meet some minimum standards and requirements and sellers want to know that fraudulent or inappropriate requests will not be tolerated.
Most World Wide Web mall or commerce sites do not offer this kind of site integrity for their business transactions, since most of them are directed primarily to retail sales in which a consumer can usually rely on consumer protection laws and some credit card “insurance” practices, for protection from the unscrupulous.
The few enterprise electronic commerce providers that go beyond the mall concept do so with the addition of a governor or administrator feature which coordinates with the enterprise application servers. The governor sets up and administers the rules for the site and can act as a broker. This usually entails a customized, specially programmed matching of participating companies' computer systems to coordinate authorization and payment approval so orders flow between firms. However, this technology can cost millions and it can take as much as two years to program the computers and set up the necessary processes and equipment at all the participating company sites. Most of the components for doing this are sold by major computer hardware and software vendors who also sell application server software, hardware, and consulting services to install the “front-end” application server at the participating business's site. Thus, while the Internet may be used to connect the companies participating, most of the work is done by the application server software installed on private, proprietary networks at the various company sites, and the Internet serves as a simple external telecommunications link.
Another complication of some of the seller—centric and enterprise application server products designed for commerce is that they may only work with certain forms of electronic data interchange (EDI) technology, which is 7 to 10 times more costly to use than other methods. Existing EDI technologies use private networks and charge per call and by the bit of information transmitted. Depending on the approach used attempting to change such systems to use other forms of data interchange can be very costly, because of the number of installed software application servers at the participating company sites which must be radically changed. Because of the expense associated with most EDI technologies, only about 2% of companies worldwide attempting to do business over a network use them.
Existing business to business enterprise application software servers tend to have more of a sellers' focus, and, as mentioned above, they tend not to focus on a buyer's need for finding and evaluating new sellers, nor for negotiating and bargaining with the new suppliers. Similarly, most of the mall Websites which focus on retail sales are seller-centric. That is, they focus on letting a seller list its wares and prices, and decide how much to disclose about itself and its products and only allow the buyer to select from listed items and prices. Little or no seller marketing, product, terms or service evaluation information is available to the buyer. As mentioned before, a buyer on a mall Website is usually not permitted to negotiate anything, simply to select from prices and payment options provided by the seller. Buyers using the enterprise application server software products cannot use them to negotiate new production purchases, but simply to process maintenance, repair or operation (MRO) orders against existing, already negotiated agreements.
Even with the seller-centric focus, most companies that provide a mall or enterprise application server business to business site offering, do not help with the marketing or promotion of the participating sellers' brands. Thus, the value of these services for the participants are often limited by the power of each company's individual brand. If the seller participants have products that are not well-recognized by brand name, an electronic commerce mall or business to business enterprise application server software service usually does not provide much added visibility or market reach. A few sites have attempted to address this by organizing along vertical market segments, such as malls devoted to the steel industry, but this alone does not provide that much additional visibility, primarily because it does not address some of the basic needs a buyer has for multivariate negotiations.
The production purchasing buyer needs to be able to collect information about sellers, and it would help to know that some entity has screened them and monitors them for adherence to some known set of standards and reputability. Additionally, production buyers today usually have to travel to a seller's physical location to get sample products. If the buyer is in the US and the seller is in Malaysia, this might costs thousands of dollars in airfares and travel expenses, just to get samples. Most existing products and services do not help with these tasks. As noted above, samples of newly engineered component parts may be critical for the buyer company's completion of its product. New systems being built by a computer maker may need power supplies or heat dissipation systems that are also new and unproven. The engineers developing the new computer systems need to be able to test their prototypes with sample, new component parts to know the whole system will work. None of the existing methods of buying over the Internet address this kind of need. Most systems are not designed from the buyer's viewpoint.
One system does attempt to address a few things from a buyer's viewpoint. This is the Priceline.com system which is described in U.S. Pat. No. 5,794,207 Method and Apparatus for a Cryptographically Assisted commercial Network System Designed to Facilitate Buyer-driven Conditional Purchase Offers, issued Aug. 11, 1998, to Walker et al., assigned to Walker Asset Management Limited. This is essentially an online bidding process in which a buyer specifies the price it desires to pay for an object, such as an airplane reservation or a car. The bid is submitted over the Internet to a central site which analyzes a database of sellers of that type of item to find one or more selling the object at close to the bid price. These matches or near-matches are presented to the buyer, who can then select from them and place a conditional purchase offer. If the seller accepts, the sale is made. A buyer can initiate another round of bidding if there is no good result from the initial one. While this system has benefits for certain types of purchases, usually of completed, commodity items, it does not address the needs of production buyers outlined above. It does not provide iterative bargaining between the buyer and seller on all aspects of a multivariate transaction, nor does it connote much, if anything about the participating sellers. It is similar to other auction sites on the World Wide Web which allow you to submit bids to a seller or auctioneer, but do not provide the opportunity to bargain interactively with the seller on all the terms. A bid submission process is quite different from a price and terms negotiation process. Bid submission systems are usually designed to assist a seller in disposing of excess inventory. Hence, some malls and enterprise server applications provide limited electronic commerce, but none provide true multivariate negotiation ability.
Finally, both the mall concept and the enterprise server concepts use databases for storing and indexing product and price lists and catalogs, along with final orders. However, since very little is offered in the way of iterative bargaining, other than a simple order/confirmation process, little or nothing is known, and consequently stored about the negotiation process on a step by step basis. Again, any information that is collected is likely to be of interest primarily to the seller, not the buyer, since most of the systems in existence are focused on the seller.
Once a complex agreement has been negotiated, printed in hard copy, and signed, it usually goes into a file system and in frequent cases virtually disappears. Six months or a year after signing, the parties to the agreement may have re-organized their companies or promoted the people involved in the original negotiation, so that new people are assigned to administer the agreement and carry on the relationship. Often times, the new individuals do not follow the agreement completely and sometimes it even gets lost in the transitions that so many companies undergo today. Thus many of the benefits that were obtained through long and hard negotiations may be lost over time.
Similarly, relying primarily on a hard copy paper trail to manually validate orders placed against an agreement is error prone. If the agreement is lost or only infrequently referred to, validation begins to erode, and correspondingly, so does the likelihood that all the benefits will be obtained. For example, additional discounts for timely order placement may be lost if the successors are not aware of the discounts.
To attempt to maintain file copies of the agreement in several different departments within a company also leaves room for error with present techniques. While the legal department may have the official copies, marketing, purchasing, engineering and manufacturing may not be as rigorous at filing and may be working from copies of the next to the last draft, or may lose copies of formal amendments.
For many companies it is important that a major agreement be available and understood by several departments. Using the example of discounts for early order placement and lack of reorders and corrections, it may be important for engineering, purchasing and manufacturing to coordinate their efforts to take advantage of this. For the design of a new product, engineering is usually responsible for determining the exact kind of components to order, while marketing, purchasing and manufacturing may need to cooperate to plan a schedule for ordering in quantities over time. While there are some systems that allow an engineering design to be turned into a parts list, there are no systems that allow an agreement to be used to inform the whole process.
Similarly, a major agreement usually involves at least two entities. Short of costly, time consuming options such as litigation or mediation, there is little available today that such entities can use to manage the agreement and the ensuing relationship it creates between them. While there are some automated systems that allow one company to place orders against a manually negotiated agreement, these systems do nothing but that. Many companies do not want to extend such a system further into their internal networks for fear of disclosing sensitive material such as pricing information, customer lists, or new technical developments.
In many industries, developments in the legal system such as the Uniform Commercial Code and IncoTerms, coupled with experience in the industry, make it easier to develop model “Standard Agreements” that companies can use as a starting point for negotiation. For the most part, however, the only way these have been used is as the basis for word processing text.
The problems associated with complex commercial negotiations are similar to those found in complex design, development and production environments. In fact, many design, development and manufacturing processes require a significant amount of negotiation.
A customer, such as a computer manufacturer, may want to include a scanner product made by a scanner manufacturer as an integral part of its new computer system. After completing the scanner vendor selection and contract negotiations process, the customer typically still faces a number of iterative negotiations with the maker of the selected scanner subsystem-however, these may have to do with the design, the development and even the manufacturing of the subsystem. For example, the computer manufacturer may want the scanner vendor to develop custom driver software for each of the three operating systems the computer manufacturer uses, and may want special features in each. The scanner vendor may be unexpectedly limited in resources and time, thus requiring that the computer maker make some selection and priority decisions. Each party may have to go back and forth numerous times with requirements documents, design documents and development timetables until a good result is achieved at each stage of the development process.
Presently, there are custom development tools developed for internal use by a supplier in specific industries, such as rapid prototyping systems for Very Large Scale Integrated (VLSI) integrated circuit chip makers, but no systems that address the ongoing negotiations between customers and suppliers that actually take place in complex design, development and production processes.
As companies and legal entities operate in the present economy, it becomes increasingly important for them to identify their respective core competencies and separate them from other processes that are done internally but may not be essential for the business. For example, a computer manufacturer may have hardware design and engineering as its core competency. Logistics management for shipping and receiving may not be a core competency, yet it may still be done internally. At present there are few analytical tools a company can use to examine its internal processes to see which are most effective and which need improvement or need to be subcontracted out. There are some consultants who will study such processes manually, and some decision support tools available, as well as the beginning of a concept called collaborative forecasting and replenishing which attempts to allow two companies to compare their respective processes. However, there is presently no automated infrastructure that can be used by consultants or systems to do this.